The present invention relates to balancing an out-of-proof transaction which includes a number of debit items and a number of credit items at a balancing workstation of an image-based check processing system, and is particularly directed to improving assistance to an operator to balance the out-of-proof transaction at the balancing workstation.
A typical image-based check processing system includes a number of balancing workstations at which out-of-proof transactions are balanced. Each transaction includes a number of debit items and a number of credit items. The total amount of the debit items is intended to equal the total amount of the credit items. When the total amounts are not equal, a particular transaction does not balance and an out-of-proof transaction exists.
To balance an out-of-proof transaction, a transaction item (debit item or credit item) causing the out-of-proof condition must be identified and then corrected. A known way of balancing the out-of-proof transaction is to apply a number of suspect tests to transaction items until the out-of-proof condition is identified and corrected. Typically, each suspect test is implemented via software and is invoked when the operator at one of the balancing workstations presses a "SUSPECT" key on a keyboard at the balancing workstation.
When a suspect test is invoked, a number of suspect transaction items is selected and presented on a display screen to the operator. The actual suspect transaction items selected and presented on the display screen to the operator depend upon the particular suspect test which has been invoked by the software. The operator then evaluates each suspect transaction item as it is presented on the display screen, and either verifies the solution to the out-of-proof problem or presses the "SUSPECT" key again to invoke another suspect test. The out-of-proof problem is solved when the correct solution is found.
The order in which the suspect tests are applied, and whether or not each suspect test is applied, usually affects the average time to solve the out-of-proof problem. It is desirable to apply suspect tests in an order which maximizes throughput of the check processing system.
A known method of prioritizing suspect tests is for the manufacturer of the check processing system to collect data from a customer, analyze this collected data, and then prioritize suspect tests in accordance with the results of this analysis. Each check processing system would have the same prioritization of suspect tests. A disadvantage in using this method is that a different customer will usually have a different prioritization of suspect tests because of different factors affecting the typical types of out-of-proof problems to be solved for that particular customer.
Another known method of prioritizing suspect tests is to provide a check processing system which allows each customer to define the order in which the suspect tests are prioritized. A disadvantage in using this method is that each customer must be studied and customized to produce optimal results. Another disadvantage is that typical out-of-proof problems may change over time and, therefore, may affect the prioritization of suspect tests.
In known check processing systems, the process of identifying and correcting a transaction item causing the out-of-proof condition may be relatively time-consuming. The process is especially relatively time consuming when there is a large number of transaction items in each transaction. When this occurs, the cost of operating the check processing system is usually relatively high.